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DIGITAL SIGNAL PROCESSING AND SIGNAL FORMAT 



BACKGROUND OF THE INVENTTON 

Field of the Invention 

5 The present invention relates to signal processors and to a signal format. In 

particular the invention relates to a signal format, a signal encoder for encoding a 
signal according to the format, a corresponding decoder, and a signal transmission 
system including the encoder and decoder. 

It is desired to transmit packetised signals such as MPEG 2 TS ( Transport 

1 0 Stream ) packets from one location or piece of equipment to another. It is known to 
transmit MPEG 2 TS packets via a DVB Asynchronous Serial Interface (ASI). DVB 
ASI is effective for the transmission of one transport stream from point to point such as 
between specific items of equipment but is otherwise relatively inflexible. 

According to one aspect of the invention, there is provided a transmission 

1 5 system in which MPEG 2 TS packets are transmitted via an SDTI system. 

Such a system provides greater flexibility than using DVB ASI. The SDTI 
(Serial Data Transport Interface ) is defined m SMPTE 305M. SDTI transmits packets 
in a signal structure comprising frames of television lines. Ancillary data is carried in 
the horizontal blanking area of lines and data is carried in a payload area of each line. 

20 The payload area is in the active line interval. SDTI allows TS packets to be routed 
wherever SDI connections are available and also allows TS packets from more than 
one source to be transmitted. However, the carriage of TS packets over SDTI requires 
buffering to ensure that the packets are confined to the payload area of the SDTI and to 
allow multiple packets on each line for efficiency. The buffering process introduces 

25 delay and jitter ( i.e. variation in the timing of the packets relative to each other ) to the 
packets but, for accurate decoding of an MPEG 2 signal, the packets of that signal 
must be provided to the MPEG decoder with accurate timing relative to one another to 
allow correct decoding. Whilst absolute delay of packets is not a problem because it 
affects all packets equally, there is a need to correct jitter at or before the MPEG 

30 decoder. 
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Whilst the foregoing discussion describes the technical problem faced by the 
present invention with reference to the transmission of MPEG 2 TS packets via SDTI, 
similar problems may occur in the transmission of other types of time sensitive packets 
over other data transmission systems. 
5 SUMMARY OF THE INVENTION 

Accorduig to another aspect of the invention, there is provided a digital signal 
comprising: data blocks, each data block including a header containing data relating to 
the block and at least one slot; each slot having a slot header relating to the slot and a 
data packet; the data packets containing successive parts of information from a source; 

1 0 a first slot which contains a first packet containing a first part of the said information 
from the source also containing a reference time; and the or each subsequent slot 
containing a subsequent packet of the information from the said source also containing 
timing information defining the timing of that packet relative to the reference time. 

According to another aspect of the invention, there is provided an encoder for 

15 encoding a digital signal comprising data blocks, each data block including a header 
containing data relating to the block and at least one slot; each slot having a slot header 
relating to the slot and a data packet; the data packets containing successive parts of 
information from a source; a first slot which contains a first packet containing a first 
part of the said information from the source also containing a reference time; and the 

20 or each subsequent slot containing a subsequent packet of the information from the 
said soiirce also containing timing information defining the timing of that packet 
relative to the reference time, the encoder comprising a clock, and means for deriving 
from the clock a reference time defining the time of production of the said first packet 
and for providing the reference time information in the said first slot and for deriving 

25 from the clock the said timing information defining the times of production of the 
subsequent packages and providing the timing information in the subsequent slots as 
the subsequent packets are produced. 

According to a further aspect of the invention, there is provided a decoder for 
decoding a digital signal comprising data blocks, each data block including a header 

30 containing data relating to the block and at least one slot; each slot having a slot header 
relating to the slot and a data packet; the data packets containing successive parts of 



information from a source; a first slot which contains a first packet containing a first 
part of the said information from the source also containing a reference time; and the 
or each subsequent slot containing a subsequent packet of the information from the 
said source also containing timing information defining the timing of that packet 
5 relative to the reference time, the decoder comprising a clock, means for detecting the 
timing information of the packets, means for initially setting the clock to the said 
reference time on detection of the said first packet, means for comparing the clock time 
with the said timing information of the subsequent packets, and means for outputting 
the packets at the times when the timing information of the packets equals the clock 
10 time. 

By providing the timing information in the signal, the decoder is enabled to 
output the packets with jitter substantially reduced and preferably eliminated to allow 
correct decoding in for example a subsequent MPEG decoder if the packets are MPEG 
TS packets. Packet jitter can corrupt the decoding. The decoder compares the timing 

1 5 information of each packet with an internal clock set by the reference time of the first 
packet and outputs the packets to, for example, a buffer when the clock time equals the 
packet time thus at least reducing the jitter. 

hi an embodiment of the invention, the blocks are payload areas in the active 
line intervals of SDTI signals which have ancillary data including address data in the 

20 non-active areas of the lines. 

hi an embodiment of the present invention as applied to SDTI, there is a fixed, 
integer, number of complete packets per SDTI line with padding (e.g. zeros) in any 
unused space. The slot lengths are thus fixed. The slots and packets on a particular 
SDTI line all have the same source and destination addresses and there is only one 

25 packet stream on that line. 

In another embodiment of the present invention as applied to SDTI, the data 
blocks are variable length blocks which may occupy one or more lines. The slots 
within the variable length data blocks are variable length slots. Preferably, the slots are 
"T L D blocks" containing a Type field T containing data describing the type of data in 

30 the Data field D and a Length Field L defining the length of the data in the data field. 
Preferably the TLD blocks are of two types: metadata blocks; and data blocks. A 



metadata TLD block precedes the data TLD block(s) containing the data described by 
the metadata. The TLD data blocks contain the reference time and timing information. 
The metadata TLD block preceding those blocks contains data identifying which of the 
blocks contains the reference time. 
5 BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other objects, features and advantages of the invention will be 
apparent from the following detailed description of illustrative embodiments which is to 
be read in connection with the accompanying drawings, in which: 

Figure 1 is a schematic diagram of the payload area of an SDTI line; 
1 0 Figures 2a to c are schematic diagrams of MPEG 2 TS packets; 

Figure 3 is a schematic diagram of an SDTI payload area divided into slots and 
having a format in accordance with an embodiment of the present invention; 

Figure 4 is a schematic diagram of the payload header structure; 

Figure 5 is a schematic diagram illustrating the correction of jitter in 
1 5 accordance with an embodiment of the present invention; 

Figure 6 is a schematic block diagram of a system, in accordance with an 
embodiment of the invention for transmitting MPEG 2 TS packets over an SDTI 
system; 

Figure 7 is a schematic block diagram of an example of the timing data inserter 
20 and of the timing corrector of the system of Figure 7; 

Figures 8 and 9 are schematic block diagrams of examples of the counters of 
Figure 7; 

Figure 10 is a schematic diagram of an SDTI variable block used in another 
embodiment of the invention; 
25 Figure 1 1 is a schematic diagram of a TLD block used in the other embodiment 

of the invention; 

Figure 12 is a schematic diagram showing a hierarchy of SDTI variable blocks 
and TLD blocks used in the other embodiment of the invention; and 
Figure 13 is a schematic diagram of a TLD compound packet. 
30 DESCRIPTION OF THE PREFERRED EMBODIMENTS 
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For convenience, the Figures represent the data in parallel-format. In practice 
the data is transmitted in serial-format. 

Overview 

5 First Embodiments: SDTI-TS 

The following description describes first examples of a novel signal format for 
carrying MPEG-2 Transport Stream packets over the SDTI (SMPTE 305M). MPEG 2 
TS and SDTI are well known and will not be described herein in detail. The novel 
format is referred to herein as SDTI TS. SDTI uses television lines to carry data. The 

1 0 active line intervals are the pay load areas and contain the STDI data blocks. The non- 
active intervals of the lines contain ancillary data including the source and destination 
addresses of the data in the active line intervals. In accordance with an embodiment of 
the present invention, to ensure efficiency of transfer, the pay load area of each line of 
SDTI-TS is filled to capacity as much as possible with whole, fixed length, slots 

15 containing the packets from one Transport Stream. The novel format includes all 
information necessary to recover Transport Stream packets with a low jitter level at the 
SDTI-TS decoder and has the flexibility to meet a nximber of design requirements. 

References 

20 The following references, which are published standards, contain information 

relevant to the present invention. 

SMPTE 305M, Serial Data Transport Interface (SDTI). 

SMPTE RP 168, Defmition of Vertical Interval Switching Point. 

ISO/IEC 13818-2: Information Technology - Generic Coding of Moving 
25 Pictures and Associated Audio Information: Video, (MPEG-2). 

ISO/IEC 13818-2: Information Technology - Generic Coding of Moving 
Pictures and Associated Audio Information: Systems, (MPEG-2). 

DVB: Interfaces for CATV/SMATV Headends and Similar Professional 
Equipment; 

3 0 Asynchronous Serial Interface (A SI) . 
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SMPTE 259M, 10-bit 4:2:2 Component and 4fsc NTSC Composite Digital 
Signals/Serial Interface. 

SMPTE 291 M, Ancillary Data Packet and Space Formatting. 



5 BackRround 

The currently established interface for the carriage of MPEG-2 Transport 
Stream (TS) packets is the DVB ASI which places packets within a small tolerance of 
the position required to ensure minimal impact on the decoder buffer. However, ASI 
cannot easily carry more than one TS, neither can ASI be supported by commonly 
10 available SDI based equipment. It is usefiil as a specialised point-to-point interface 
between specific items of equipment. 

Illustrative examples of the present invention 

One aspect of the present invention proposes the carriage of MPEG2 TS 

15 packets over the SDTI. This allows a more general approach to connectivity by 
allowing TS packets to be routed wherever SDI connections are available. However, 
the carriage of TS packets over the SDTI requires buffering to ensure that packets are 
confined to the payload area of the SDTI and to allow multiple TS packets on each Ime 
for efficiency. The resuh of this buffering process is to introduce both a delay and 

20 jitter to the packet stream. The delay is not a problem which concerns the present 
invention. The examples of the present invention described herein allow the packet 
jitter to be reduced to insignificant levels. As a benchmark, the present embodiments 
allow a DVB- AS I input to be carried through SDTI-TS and decoded to create a new 
DVB- ASI signal with minimum additional jitter. The SDTI-TS can also operate 

25 directly from other interface points as required. 

SDTI PARAMETERS 

SMPTE 305M specifies the SDTI for bit rates of 270Mbps and 360Mbps and 
examples of the invention may operate on both bit rates and at higher bit rates. The 
30 examples of SDTI-TS described herein use the fixed block size mode of the SDTI with 
one block per line. The format of each fixed length block is shown in Figure 1 . The 



block is either 1438 or 1918 bytes long including a ten bit SDTI-TYPE word as 
described hereinafter. The block typically includes an additional 2 bytes of error 
detection CRC for a total of 1440 or 1920 bytes as shown in Figure 1. 

5 TYPE WORD 

The SDTI data block has a block type word. 

For 270Mbps SDTI, the Block Type value is "Olh" which specifies a block size 
of 1438 words per line (including the Type value). 

For 360Mbps SDTI, the Block Type value is "09h" which specifies a block size 
10 of 1 9 1 8 words per line (including the Type value). 

The SDTI Data Type word has a suitable value: there is no assigned value at 
present. 

The input format is 8 bit data entered into bits b7 -bO of a 10 bit word. Bit b8 
of the 10 bit word is the even parity of bits b7-b0 and bit b9 is the complement of bit 
15 b8. 

The optional FEC (Forward Error Correction) may be added to the block to 
give added data security. Whether FEC is added or not, bits b7 and b6 of the Block 
Type word are set according to SMPTE 305M. 

The present examples of the invention do not use the Data Extension facility of 
20 SMPTE 305M. It is recommended to avoid use of the SDI switching lines as defined 
in SMPTE- RP 168 

MPEG-2 TRANSPORT STREAMS 

As shown in Figure 2a, MPEG-2 TS (Transport Stream) packets are 188 bytes 

25 in length. As shown in Figure 2b if DVB Forward Error Correction (FEC) is added, 
then the packet length is 204 bytes. The MPEG-2 TS FEC is interleaved across 
packets and designed for correcting serious data loss through transmission errors which 
may be bursty. Whilst in extreme cases SDTI can create occasional errors, the MPEG- 
TS FEC is unsuitable for correcting SDTI errors due to the interleave length and this 

30 FEC will not exist if the packets carried are only 188 bytes in length. Consequently, 
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the SDTI-TS format of an embodiment of the invention includes an optional FEC to 
correct for any errors which may occur through the SDTI link. 

PAYLOAD FORMAT 

5 In accordance with the first embodiments of the invention, the MPEG-2 TS 

packets are wholly contained in an SDTI fixed block placed in a TS Payload format an 
example of which is described as follows with reference to Figure 3. The illustrative 
TS Payload format has a 2 layer structure as indicated in Figure 3. The payload has a 
TS Payload header defining parameters which apply to the whole payload line, and a 

10 fixed number of TS Slots into which the MPEG2 TS packets are placed. Each TS Slot 
has a slot header which defines parameters associated with the TS packet in the slot, 
followed by the TS packet itself and terminated by an optional SDTI RS-FEC of 6 
bytes. 

15 TS Payload Structure 

The SDTI Type word of the TS Payload is the type word at the left hand side of 
figure 1. The bit assignments of the Slot Count, Channel Handle and Continuity Count 
words are shown in Figure 4. 

20 TS Payload Slot Count 

The Slot Count is an 8 bit word which defines the number of TS Slots for this 
Payload line. The number of TS Slots has a lower value of 1 and an upper value 
defined by the payload length. In the case of 270Mbps SDTI, the maximum number of 
TS Slots is 6. In the case of 360Mbps SDTI, the maximum number of TS Slots is 8. 

25 Higher SDTI rates can support appropriately higher numbers of TS Slots in the payload 
area. In the present embodiments of the invention, data space between the last TS 
Payload Slot and the SDTI CRC words is not used for any other purpose or 
application. Lower values of payload slot count tend to reduce the codec delay. 
Further information on this topic is given herein below. 

30 

TS Payload Channel Handle 
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The Channel Handle is a 1 6 bit word organised as two 8 bit words with the 
most significant word first. This word is used to distinguish between TS Payload lines 
having the same SDTI source and destination header addresses but representing 
different channels of TS transmission. In the present embodiments the Channel 
5 Handle value is set to "OOOOh" but other values may be chosen. 

TS Pavload Continuity Count 

The "Continuity Count" is a modulo 65536 count which increments by 1 for 
every TS Payload line having the same SDTI Source and Destination addresses and the 
10 same Channel Handle value. The purpose of this count is to provide detection of 
signal path switching. 

TS Slot Structure 

In the present embodiments every TS Slot is 216 words in length and TS Slots 
1 5 are arranged in continuous order immediately following the TS payload header. 
A TS Slot contains information in the following sequence: 
a TS Slot header of 2 word length, 

a coarse count value of 2 words in length clocked at 2.25MHz, 
a fine count which is one word in length clocked at a multiple of 2.25MHz. 
20 a 188 byte TS Packet, 

a 16 byte space for the optional MPEG-2 TS FEC, 
a 6 byte space for the optional SDTI-TS FEC and 
a 2 byte null data space. 

25 TS Slot Header 

The TS Slot header is an 8 bit word with bits b7-b0 defined as follows: 

Bit hi defmes whether the TS Slot has an active SDTI FEC. 

hi is "0" if the SDTI FEC is not active and is " 1 " if the SDTI FEC is active. 

Bits b6-b3 are reserved but not defmed. 
30 Bit b2 is a TS discontinuity flag. If the TS packet in this TS slot is not related 

to the previous TS packet, the b2 is set to "1", else it is set to "0". A discontinuous 



TS packet (i.e. h2-V) also indicates that this is the first packet in a new TS packet 
sequence. 

Bits bl and bO form a code which define the TS packet type as follows: 
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bl hi TS Type 

0 0 188 byte TS packet with no 1 6 byte FEC . 

0 1 Reserved but not defined. 

1 0 204 byte TS packet with an inactive 16 byte FEC 
1 1 204 byte TS packet with an active 16 byte FEC. 



TS Slot Coarse Count 

The coarse count value is derived from a modulo 65536 counter clocked at 
2.25MHz at the SDTI-TS encoding point and defines the coarse timing of the TS 
packet for the decoder to be able to output the TS packet at the correct time relative to 
the previous TS packet. This coarse timing is used in conjunction with the next word, 
the TS Slot sub count which contains a fine timing derived from a clock at an integer 
multiple of 2.25MHz to provide a clock with a reference timing close to that of the TS 
Program Clock Reference (PCR). The coarse and fine timing are preferably derived 
from the same master clock which is for example the PRC clock operating at 27 MHz. 

It is not required for the 2.25MHz counter to match the period of the PCR of 
27 hours. The 2.25MHz counter only needs a sufficient cycle period guaranteed to be 
longer than the maximum period between TS packets. The 2.25MHz cycle period is 
approximately SOmsecs. The 2.25MHz counter increments by 1 for every 12 
increments of the PCR. 



TS Slot Sub Count 

In the case of 270Mbps SDTI, the sub count is clocked by a 27MHz clock 
(which is at the same rate as the PCR) and counts over the range 0 to 11 . In the case of 
360Mbps SDTI, the sub count is clocked by a 36MHz clock (which is at a higher rate 
than the PCR) and counts over the range 0 to 15. The number of bits available for the 
Sub Count value allows SDI word (parallel) clock rates up to 576MHz. How the TS 
Slot counts can be used for output timing control is described herein later. 



TS Packet Data 
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The 204 byte space for the TS packet is a fixed allocation. The contents of this 
space are filled with 188 byte or 204 byte TS packet data as defined by bits bl and bO 
of the TS slot header word. In the cases of 188 byte TS packets and of 204 byte TS 
packets with inactive TS FEC, the 16 byte TS FEC space is null filled. 

5 

TS Slot RS FEC 

The FEC is applied over the 214 bytes of the TS slot fiom the 2.25MHz count 
word to the last word of the FEC. If the TS slot header word FEC valid bit (b7) is set 
to "0", then all 6 words of the FEC are set to "OOh". The FEC is a Reed-Solomon, R- 
10 S(214, 208, T=3) shortened code fi:om the original R-S(255, 249, T=3) code. 
The R-S code generator polynomial is: 

R - Six) = (x®a° ).(x e a' ).(x 0 ).(x © ).(x ® a" ).{x @a') 

15 where a is defined by Galois Field GF(256) generator polynomial: 

GF(x) = x' ex' ©x' ©x' ©1. 

TS Slot Null Space 
20 The TS slot ends with 2 words of zero filled null space. 

USING THE TS SLOT TIMING DATA 

Figure 5 illustrates the SDTI-TS coding process fi:om the MPEG-2 TS packet 
stream input to output through the SDTI-TS format The combination of the TS Slot 
25 2.25MHz count and the sub count values defines a count value with a resolution at 
least as high as the PCR and with a period before repetition of approximately SOmsecs. 
On reception of the first TS packet in a sequence, the decoder may output the packet 
whenever it is ready and, at the same time, sets an internal counter running at the SDTI 
word rate (27/36MHz) to the TS slot count value. This counter counts in the same 
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manner as defined for the 2.25MHz count and sub coimt. Thereafter, for all remaining 
packets, the decoder outputs a packet when the decoder counter equals the counter 
stored in the TS slot count thus guaranteeing the mtegrity of the output TS packet 
timing. La the case of 270Mbps SDTI, the count value clocks at the same rate as the 
5 TS packet PCR and should result in no timing jitter, hi the case of 360Mbps SDTI, the 
count increments by 4 for every 3 increments of the TS packet PCR, therefore, 
resulting in plus or minus 1 PCR clock jitter. This value is well within the MPEG-2 
defined limits. 

10 SYSTEM DELAY CONSIDERATIONS 

The payload area of each SDTI line is packed with as many complete slots and 
thus TS packets as possible. In the present embodiments the slots are of fixed length 
and the SDTI payload area contains only complete slots. Spare space in a payload area 
is filled with zeros. This ensures that the waste of SDTI lines is muiimised and thus 

15 the maximum number of lm.es are available for the transfer of other data. The 
following examples are based on 270Mbps SDTI-TS. At a bit rate of 4Mbps, 
approximately 15 lines per frame (525/30) are used for the carriage of MPEG-2 TS 
packets and the codec delay is just over 2msec. At a bit rate of 50Mbps, approximately 
185 lines per frame (525/30) are used for the carriage of MPEG-2 TS packets and the 

20 codec delay is thus reduced to around 200usec. To a first approximation, the codec 
delay is inversely proportional to the bit rate. Thus at low bit rates, delay can only be 
reduced by reducing the number of TS packets per line and thus occupyuig 
proportionately more SDTI lines. If the 4Mbps example above occupied only 1 TS 
packet per line, then the delay would be reduced to approximately 400 usee. 

25 

Example of an SDTI TS system 

Referring to Figure 6 there is shown an example of an SDTI TS system. The 
system comprises a data source 1. The data source I includes an MPEG2 encoder 2 
which is known and which produces known MPEG 2 TS packets. The packets may or 
30 may not include the EEC data, as shown in Figures 2a to 2c. The packets are outputted 
from the MPEG encoder with the correct relative timing: i.e. they are relatively jitter- 



free. A timing data inserter 4 of the source 1 (and described in more detail with 
reference to Figures 7 and 8) inserts the coarse and fine timing data into a header. The 
timing data defines the correct timing of the packets relative to a reference time. The 
MPEG2 TS packets with the timing data are fed to the SDTI 6. The SDTI 6 also 
receives packets and other data from other sources 3 and 5. The other sources may or 
may not be the same as source 1. The SDTI routes the data from the sources 1, 3 and 5 
in known manner to respective corresponding destinations 11, 13 and 15. For that 
purpose one SDTI line has a source address and a destination address in its ancillary 
data and carries only data from the addressed source to the addressed destination. As 
described above the MPEG2 TS packets are buffered in the SDTI so that they incur 
jitter. At the destination 1 1 the packets from source 1 are subject to timing correction 
in corrector 8 before delivery to an MPEG decoder with the correct timing. An 
example of the corrector 8 is described with reference to Figure 7. 

The SDTI assembles the MPEG2 TS packets into the slots shown in Figure 3 
adding the slot header data to the timing data and adding the block header data, as also 
shown in Figure 3, to the block. The SDTI also adds the 6 byte FEC, the zeros for the 
null space and the optional SDTI CRC. The SDTI also determines when a packet is 
the first packet of a new packet sequence and sets the bit b2 of the TS discontinuity 
flag to'l'. 

Referring to Figure 7, an example of the timing data inserter comprises a 
27MHz clock 40 which clocks a counter 42 to produce the timing data. The clock 40 
is derived Jfrom the SDTI clock. An example of the counter is shown in Figure 8. The 
counter comprises a Modulo 12 counter 80 clocked at 27MHz which produces the fine 
timing data and which produces a 2.25MHz clock for clockmg a Modulo 65536 
counter 82 which produces the coarse timing data. The counters 80 and 82 are fi:ee 
running. A latch 44 temporarily stores the fine and coarse covmts. Upon receiving a 
packet start signal it feeds the current counts to a multiplexer 46 which inserts the 
timing data into the bit stream at the start of the packet. The first packet of a packet 
sequence is allotted whatever arbitrary time is indicated by the counter 42 at the 
moment of its production. That time is a reference time for the subsequent packets of 
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the sequence. The coarse counter 82 sequences through its counts with period of 
65536/(2.2 5 * 10^) seconds or about 30 ms. 

At the destination, an example of the corrector 8 comprises a demultiplexer 84 
which detects the slot header and determines therefrom whether a packet is the first in 
5 a sequence as indicated by the discontinuity flag (b2=l) and the fine and coarse timing 
data. The demultiplexer separates the MPEG2 TS packet from the slot header and 
feeds the packet to a FIFO buffer 96. The FIFO buffer 96 stores one SDTI block of 
packets. The packets are on average clocked into and out of the FIFO at the same rate 
e.g. 270 M bits per second as they are originally produced at the source 1. However, 

1 0 the packets may be input irregularly but are output continuously with correct timing. 
The demultiplexer feeds the timing data to a comparator 88 via another FIFO 86 and 
directly to a gate 94. If the packet is a first packet, the discontinuity flag b2= 1 enables 
the gate 94 to load the timing data, which represents the reference time, into the 
counter 90, thereby setting the counter to the reference time. 

1 5 The counter 90 an example of which is shown in Figure 9 comprises a modulo 

12 counter 921 and a modulo 65536 counter 941 arranged identically to the 
corresponding counter 80 and 82 of Figure 8 and counting a 27MHz clock provided by 
the SDTI. The clock provided by the SDTI is synchronous in known manner with the 
source clock 40. The counters 921 and 941 differ from the counters 80 and 82 in that 

20 they can be preloaded with the reference count. Once loaded the counters 921 and 941 
are free- running in the same way as the counters 80 and 82 and are thus in delayed 
synchronism with them. The comparator 88 compares the timing data from the 
demultiplexer with the timing data from the counter 90. When the compared timing 
data are equal, the comparator enables the FIFO 96 to output a packet with the correct 

25 timing. 

The packets and the timing data are separated by the demultiplexer 84 and fed 
into the FIFOs 86 and 96. The FIFOs contain corresponding sequences of packets and 
timing data. As the packets are moved through the FIFO 96 to its output, so are the 
corresponding timing data moved through the FIFO 86 to maintain correspondence 
30 with the packets in the FIFO 96. After each item of timing data reaches the output of 
the FIFO 86 that item is cleared from the FIFO. Each item of timing data at the output 



of the FIFO 86 is compared with the count in the counter 90 and when the count 
represented by the timing data equals the count in the counter, a read out enable signal 
causes the FIFO 96 to start readmg out the corresponding packet which accordingly has 
the correct timing. The enable signal also clears the timing data from the output of the 
FIFO 86 and moves the next item of timing data to the output to be compared with the 
count in the counter 90. 

Second Embodiments: SDTI-PF 

Figures 1 to 4 describes a signal format referred to herein as STDI-TS which 
uses the fixed block size mode of the SDTl will one block per line. That signal format 
is described in the context of transporting MPEG 2 bit streams using the SDTL The 
following description describes another version of the signal format referred to herein 
as SDTI-PF. This format SDTI-PF allows MPEG2-TS packets to be transported and 
also allows for other kinds of packet to be carried over the SDTI, with or without 
buffering to reduce packet jitter. Such packets may be ATM cells and packets based 
on the Unidirectional Internet Protocol (Uni-IP). 

This embodiment provides several features for the carriage of packet streams 
such as: 

A high packing density. 

A flexible arrangement of data packet types and associated packet metadata. 

Carriage of multiple charmels of multiple data packet types. 

Provision for a powerful Forward Error Correction (FEC) specification. 

The ability to reproduce accurate data packet output timing. 

The ability to add embedded user information. 

The control information associated with data packets can be used to: 

Provide a continuity counter to detect SDI switching. 

Provide a charmel 'handle' for transfers of multiple channels of data packets 
between the same source and destination addresses. 

Define the position of a data packet in a stream. 

SDTT PARAMETERS 
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SMPTE 305M specifies the SDTI for bit rates of 270Mbps and 360Mbps and 
this embodiment may operate on either 270Mbps only, or on both bit rates according to 
the equipment specification. The SDTI-PF uses the Variable Block mode of SDTI as 
shown in figure 10. The 'Separator' and 'End Code' words are special 10 bit values 
defined in SMPTE 305M. All data in the space between the 'Separator' and 'End 
Codes' are 10 bit words where 

the data comprises 8 bits entered into bits bO to b7 of the 10 bit word, 

bit b8 is set to even parity of bits bO to b7, and 

bit b9 is set to be odd parity. 

The 'Block Type' word of the SDTI header is set to Variable Block mode 
according to SMPTE 305M. 

The SDTI Data Type word is set to the value 'llh' indicating the Data packet 
Format (PF) variable block payload. 

This embodiment does not use the Data Extension facility of SMPTE 305M. 

SDTI LINE AND ADDRESS NUMBERS 

Since the data in each SDTI variable block may continue through as many lines 
as necessary until the block end, it is necessary that the SDTI header line numbers are 
contiguous. It is also necessary that the SDTI header source and destination address 
values are constant throughout the transmission of all lines associated with any one 
SDTI variable block. 

SDTI SWITCHING 

The arbitrary switching of SDTI data streams, although at the picture frame 
boundary, may affect the ability to successfully decode the contents of data packets 
without the use of special processing equipment to mitigate the switching effects. The 
lines affected by a picture switch are defined in SMPTE RP168. It is recommended to 
avoid the use of the lines defined by SMPTE RP168 together with the lines 
immediately prior to and following the switch line where transient conditions may 
occur. A continuity count can be provided to indicate variable blocks affected by a 
switch. 
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TLD BLOCK STRUCTURE 

The Data Block area of each variable block is filled with one or more blocks 
defined by a Type, Length and Data (TLD) construct as shown in figure 1 1 . 
The three components of the TLD construct are: 
5 Type: the type of data contained in the 'value' area as a local 1 -byte label, 

Length: the length of the value, and 
Data: the data as defined by the Type. 

'Type' is a single byte which identifies the type of data carried in the TLD 
block. The Type value may identify either one kind of TLD packet (such as an MPEG- 
10 2 TS packet) or one kind of TLD metadata. 

When a TLD metadata block is received, the metadata contained in the value 
area applies to all subsequent TLD packet blocks until either the end of the SDTI 
variable block or until a new TLD metadata construct of the same type is received. 
The data fi'om a TLD metadata block does not carry any significance cross SDTI 
15 variable blocks, so each new variable block carries a new set of TLD metadata as 
needed. 

Figure 12 illustrates a hierarchy of SDTI variable blocks and TLD blocks 
according to an embodiment of the present invention. As shown in figure 12 the data 
block area of each SDTI 'Variable Block' is wholly filled with TLD blocks. There is 
20 no padding either at the start of the SDTI 'Data Block', or between TLD blocks or 
between the end of the last TLD block and the SDTI 'End Code'. 

TLD TYPE 

The TLD Type is a 1 byte word used to identify the type of data in the TLD 

25 block. 

The following rules apply to the assignment of Type values: 
A Type value of 'OOh' is not used. 

Type values ia the range 'Olh' to 'OFh' are used to identify TLD metadata 

blocks. 
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Type values in the range from 'lOh' to 'FFh' use only the most significant 4 bits 
of the Type word to identify TLD packet types. Thus only 15 of these TLD types can 
be identified. 

The least significant 4 bits of Type words with a value greater than 'OFh' are as 
follows: 

Bit b3 is used to identify the presence of an FEC at the end of the TLD data 
area. If b3 = '1' then the FEC is present, else the FEC is not present and no space is 
allocated. 

Bit b2 is used to identify if the data contains an embedded counter. If b2 = '1', 
then the embedded counter is present, else the embedded counter is not present and no 
space is allocated. 

Bits bl and bO form a binary value in the range 0 to 3. 

If the value = '3', then 6 user bytes are contained at the head of the TLD data 

area. 

If the value = '2', then 4 user bytes are contained at the head of the TLD data 

area. 

If the value = T, then 2 user bytes are contained at the head of the TLD data 

area. 

If the value = '0', then no user bytes are contained at the head of the TLD data 

area. 

TLD LENGTH 

The Length of a TLD block specifies the length of the TLD Data. Thus the 
Length value can be used to skip to the next TLD block if needed. 

The TLD Length is a variable length word defined as follows: 

If the value of the first byte lies in the range 'OOh' to TEh', then the length is 
given by the value of the first byte. 

If the value of the fu-st byte is equal to TFh' then the Length value is contained 
in the 2 bytes which immediately follow. 

Thus TLD constructs with data blocks having a length of greater than 254 bytes 
result in a length of 3 bytes of which the first byte is equal to the value of 'FFh' and the 
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next two bytes contain a Length whose value may range from 'OOOOh to 'FFFEh'. The 
2-byte Length value of 'FFFFh' is reserved for future possible expansion. 



TLD BLOCK 

TLD blocks defined by a Type value up to 'OFh' contain metadata of a format 
defined in the Metadata Defmitions below. 

TLD blocks defined by a Type value above 'OFh' contain data packets as 
defined in the Packet Definitions below. 

A Data packet may be formed firom the following components: 

User data of length 0, 2, 4 or 6 bytes. The length of the user data is defmed by 
bits bO and bl of the Type word; 

A Minor Count value in combination with a Major Count value giving 3 bytes 
which can be used to re-time the data packets at the decoder output with negligible 
jitter; and 

A Reed-Solomon Forward Error Correction (RS-FEC) of 6 bytes length. 

The TLD packet is shovm in figure 13. At its simplest level, a data packet with 
a TLD Type identifier which has the 4 LSBs set to '0' becomes a simple data packet 
containing only the packet data and no extra components. 

USER DATA AREA 

User data space is defined in increments of 2 bytes allowing 0, 2, 4 or 6 bytes 
of User Data area. The contents of the User Data area are private data and not defined 
herein. 

PACKET TIMING COUNTER 

The combination of Major and Minor Count values forms the Packet Timing 
counter with integer and fractional parts defined by the Major and Minor Count words 
respectively. The Packet Timing counter defines the timing of the start of each packet 
for a decoder to be able to output the packet at the correct time relative to the first 
packet in any stream. The Packet Timing counter can provide output packet start 
positions timings which are as accurate as the SDTI clock period. 
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The packet timing counter has a cycle period of approximately 30msecs. The 
maximum period between packets is less than the packet timuig counter cycle period to 
guarantee correct operation. 

The description of figures 5 to 9 describes how the Packet Timing counter can 
be used for accurate output timing control. 

MINOR COUNT 

The minor count corresponds to the fine slot sub count described hereinabove. 

The 8-bit Minor Count word is a value sampled from a counter clocked by the 
SDTI word clock. Bits cO to c7 of the Minor Count word are used for the minor count 
value. Bit cO is the least significant bit of the minor count value. 

In the case of 270Mbps SDTI, the minor count value is loaded from a counter 
clocked by a 27MHz clock (which is at the same rate as the MPEG-2 TS PCR) and 
counting over the range 0 to 1 1 to create a 2.25MHz clock period. 

In the case of 360Mbps SDTI, the minor count value is loaded from a counter 
clocked by a 36MHz clock (which is at a higher rate than the MPEG-2 TS PCR) and 
counts over the range 0 to 15 to create a 2.25MHz clock period. 

The number of bits available in the Minor Count word allows SDTI word clock 
rates up to 576Mhz. 

MAJOR COUNT 

The major count corresponds to the coarse count described hereinabove. The 
16-bit Major Count word is a value sampled from a modulo 65536 counter clocked by 
the 2.25MHz clock. The Major Count value is formed from bits CO to C15 as shown 
in figure 4 representing, respectively, the LSB to the MSB of the count value. 

R-S FEC 

Where provided, the R-S FEC provides correction for the whole TLD structure 
content from the TLD Type word to the last R-S FEC word. The R-S FEC is not 
interleaved over multiple TLD packets. In this embodiment, the error correction is 
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defined as a Reed-Solomon R-S (L, L-6, T=3). Where L<255, then the RS-FEC is a 
shortened code from the origmal R-S (255, 249, T=3) code. 
The R-S code generator polynomial is: 

R - Six) = (x® a°).{x @a'Ux @ a" \{x 0 a').(x © a' ).(x © a' ) 
where a is defined by Galois Field GF(256) generator polynomial: 
GF{x) = x^ ©x^ ©x^ ©x^ ©1. 

Note that although the encoder provides the capability of correcting 3 errors, a 
decoder may choose to correct only 1 or 2 errors to preserve residual error detection 
performance. 

Note also that the RS-FEC can only be applied to TLD structures of 255 bytes 
or less. Thus a TLD length value of greater than 253 will exceed the RS-FEC limit and 
thus is not applied. 

TLD BLOCK DEFfNITIONS 

The following list of definitions is that currently preferred. Extensions to this 
list may be made. 

Each TLD, (Type, Length, Data, also referred to as Key, Length, Value) 
metadata defmition has both a local identifier defmed by the 'Type' value and a global 
identifier which defines the place of the metadata item in the SMPTE Dynamic 
Metadata Dictionary. Both identifiers are referencing the same metadata specification. 
The reason for the shortened Type value is for ease of parsing the data at the high 
speeds used by the SDTI transport. There is also a gain in packing density and hence 
simplified storage requirements on high speed silicon. But it should be noted that any 
metadata item specified in this document may be expanded to define the fixll K-L-V 
construct on which the Metadata Dictionary is based. This fully expanded K-L-V (key, 
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length, value) construct may then be used as a basis for the common mterchange of 
metadata items between different applications. 



METADATA DEFINITIONS 
CONTINUITY COUNT 
Local Type value 'Olh' 

The Continuity Count is a 16 bit, modulo 65536 value which increments by 1 
for every SDTI-PF variable block having the same SDTI Source and Destination 
addresses. The purpose of this count is to provide detection of signal path switching. 

The bit significance is LSB first. Thus the LSB lies at bit bO of the first byte 
and the MSB lies at bit hi of the second byte. 

CHANNEL HANDLE 
Local Type value = '02h' 
Length = 2 bytes. 

The Slot Handle is a 2 byte word which is used to distinguish between packets 
within a SDTI-PF variable block havmg the same SDTI source and destination header 
addresses but representing dilSerent packet channels. A Slot Handle is set to zero 
where all packets associated with the same SDTI Source and Destmation Addresses are 
fi'om a single channel. Where 2 or more channels of packet streams are multiplexed 
onto SDTI-PF variable blocks, the Slot Handle values for each channel is non-zero. 
The number of multiplexed channels is limited to 65535. 

If the Channel Handle metadata is not present in SDTI-PF variable block, then 
the TLD blocks are considered to be fi:om one channel. 

STREAM POSITION INDICATOR 
Local Type value '03h' 
Length = 1 byte. 

The packet stream position indicator is used to identify the position of the 
following TLD packet in a stream. 
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Bits b2 to bO define the position of the following TLD packet in a stream of 
packets. These 3 bits identify 8 stream states as follows: 

0 = the TLD packet position in a stream is undefmed. 

1 = the TLD block contains a stream head packet which is any packet which 
precedes the stream start packet (e.g. pre-roll packets) 

2 = the TLD block contains a stream start packet which is the first packet of a 

stream. 

3 = the TLD block contains a mid-stream packet which is any packet between 
the stream start and stream end packets. 

4 = the TLD block contains a stream end packet which is the last packet of a 

stream. 

5 = the TLD block contams a stream tail packet which is any packet which 
follows the stream end packet (e.g. post-roll packets). 

6 = the TLD block contams both a stream start packet and a stream end packet 
signifying a stream of length 1. 

7 = reserved but imdefined. 

Bits hi to b3 are reserved but undefmed. 

TLD PACKET DEFINITIONS 

The following packet types are defined only be the local TLD Type Word. 
MPEG-2 TRANSPORT STREAMS 
Type value = '8xh' 

Length ^ variable depending on the presence and type of embedded FEC 
together with the presence of User, Count and FEC components. 

MPEG-2 Transport Stream (MPEG-2 TS) packets are 188 bytes in length. If 
Forward Error Correction (FEC) has been added, then the packet length is increased to 
204 bytes for DVB emission and 208 bytes for ATSC emission. The MPEG-2 TS FEC 
may be interleaved across packets and is designed for high levels of data loss through 
transmission systems which may introduce error bursts. Whilst in extreme cases SDTI 
can create occasional errors, the MPEG-2 TS FEC is unsuitable for correcting SDTI 
errors due to the interleave length and this FEC will not exist if the packets carried are 
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only 188 bytes in length. Consequently, the SDTI-PF format includes an optional non- 
interleaved FEC to correct for any errors which may occur through the SDTI link. 

Figures 2a to 2cd illustrate MPEG-TS packets with different FEC capabilities. 
It is permissible for SDTI-PF TS blocks to use all three services, User data, Re- 
5 timing and RS-FEC as needed. 

SDTI-CP TRANSMISSION PACKETS 
Type value = '9xh' 

Length = variable depending on the presence of User, Count and FEC 
10 components. 

SDTI-CP Transmission packets adopt a packet structure based on 188 byte 
MPEG-2 Transport Stream packets and are managed in an identical manner. 

UNIDIRECTIQNAL INTERNET PROTOCOL PACKETS fUNI-IP) 
15 Type value = 'Axh' 

Length = variable up to 65535 bj^es. 

Because Uni-IP packets can have a length in excess of that capable of being 
handled by the RS-FEC, Uni-IP packets would not normally be able to use FEC. 
However, if the Uni-IP packets are constrained by the sovirce device to be less than the 
20 limit set for correct FEC operation, then it may be used with success on only those 
packets which are below 254 bytes in length. Users should also be cautioned that some 
RS decoders rely on a fixed packet length in order to operate correctly in a pipelined 
operation. So Uni-IP packets with fluctuating packet lengths may cause decoder 
problems if the RS-FEC is active. 

25 

ATM Cells 

Type value = 'Bxh' 

Length = 53 bytes. 

ATM cells have a fixed length of 53 bytes to which the User, Coimt and FEC 
30 may be added as needed. 
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Although illustrative embodiments of the invention have been described in 
detail herein with reference to the accompanying drawings, it is to be understood that 
the invention is not limited to these precise embodiments, and that various changes and 
modifications can be effected therein by one skilled in the art without departing from 
the scope and spirit of the invention as defined by the appended claims. 
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WE CLAIM : 



^^yX^^ encoder for encoding a digital signal comprising data blocks, each 
data block including a header containing data relating to the block and a plurality of 
5 slots; each slot having a slot header relating to the slot and a data packet; the data 
packets containing successive parts of information from a source; a first slot which 
contains a first packet containing a first part of the said information from the source 
also containing a reference time; and the or each subsequent slot containing a 
subsequent packet of the information fi-om the said source also containing timing 

1 0 information defining the timing of that packet relative to the reference time the encoder 
comprising a clock, and means for deriving from the clock a reference time defining 
the time of production of the said first packet and for providing the reference time 
information in the said first slot and for deriving from the clock the said timing 
information defining the times of production of the subsequent packages and providing 

15 the timing information in the subsequent slots as the subsequent packages are 
produced. 

2. An encoder according to claim 1, wherein the timing information 
comprises coarse and fine timing information. 

20 

3. An encoder according to claim 2, wherem the clock comprises an input 
for receiving a clock signal, a modulo n counter which counts the clock signal and 
divides the clock signal fi-equency by n to produce the fine time information and a 
modulo m counter which coimts the frequency divided clock signal produced by the 

25 modulo n counter, to produce the coarse time information, wherein m is much greater 
than n. 

4. An encoding according to claim 3, wherein the clock signal fi-equency is 
2.25n Mhz, where n is an integer. 

30 
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5. An encoder according to claim 4, wherein the clock signal frequency is 
27MHz, n is 12 and m is 65536. 

6. An encoder according to claim 4, wherein the clock signal frequency is 
36MHz, n is 16 and m is 65536. 
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7. An encoder according to claim 1, comprising a multiplexer for inserting 
the time information in the slots. 

8. An encoder according to claim 1, forther comprising means for 
5 inserting into the slot header a flag indicating whether the slot contains a said first 

packet. 

9. An encoder according to claim 1, wherein the said dat blocks are 
variable length blocks. 

10 

10. An encoder according to claim 9, wherein the said slots are variable 
length slots. 

11. An encoder according to claim 10, wherein the variable length slots 
15 comprise slots containing metadata and slots containing data described by the 

metadata. 

12. An encoder according to claim 1 1, wherein a metadata slot precedes the 
data slots containing the data described by the metadata in the metadata slot. 

20 

13. An encoder according to claim 12, wherein the metadata slot contains 
metadata identifying a succeeding slot which contains a said first packet. 

14. An encoder according to claim 11, wherein the variable length slots 
25 comprise a data field, a Type field containing data describing the type of data in the 

Data field and a Length Field defining the length of the data in the data field. 

15. An SDTI system including an encoder according to claim 1. 

30 16/ A decoder for decoding a digital signal comprising data blocks, each 

data blbck including a header containing data relating to the block and a plurality of 
29 



slots; each slot having a slot header relating to the slot and a data packet; the data 
packets containing successive parts of information from a soiirce; a first slot which 
contains a first packet containing a first part of the said information fi-om the source 
also containing a reference time; and the or each subsequent slot containing a 
5 subsequent packet of the information firom the said source also containing timing 
information defining the timing of that packet relative to the reference time the decoder 
comprising a clock, means for detecting the timing information of the packets, means 
for initially setting the clock to the said reference time on detection of the said first 
packet, means for comparing the clock time with the said timing infon-nation of the 
1 0 subsequent packets, and means for outputting the packets at the times when the timing 
information of the packets equals the clock time. 

17. A decoder according to claim 16, wherein the timing information 
comprises coarse and fine timing information. 

15 

18. A decoder according to claim 17, wherein the clock comprises an input 
for receiving a clock signal, a modulo n counter which counts the clock signal and 
divides the clock signal frequency by n to produce the fme time uiformation and a 
modulo m counter which counts the fi-equency divided clock signal produced by the 

20 modulo n counter, to produce the coarse time information, wherein m is much greater 
thann. 

19. A decoder according to claim 18, wherein the clock frequency is 
2.25MHz, wherem n is an integer. 

25 

20. A decoder according to claim 19, wherein the clock signal frequency is 
27MHz, n is 12 and m is 65536. 

21. A decoder according to claim 19, wherien the clock signal frequency is 
30 36MHz, n is 1 6 and m is 65536. 
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22. A decoder according to claim 16, for use with a signal the slot header of 
which contains a flag indicating whether the slot contains a said first packet, the 
decoder comprising a demultiplexer for separating the flag and the packet, and means 
responsive to the flag for setting the clock to the reference time if the flag indicates a 

5 first packet. 

23. A decoder according to claim 16, wherein the outputting means 
comprises a FIFO buffer. 

1 0 '2a. a transmission system in which MPEG 2 TS packets are transmitted via 

an ^CTI system. 

2X A digital signal comprising: data blocks, each data block including a 
head^ containing data relating to the block and at least one slot ; each slot having a 

1 5 slot header relating to the slot and a data packet; the data packets containing successive 
parts of information from a source; a first slot which contains a first packet containing 
a first part of the said information from the source also containing a reference time; 
and the or each subsequent slot containing a subsequent packets of the information 
from the said source also containing timing information defining the timing of that 

20 packet relative to the reference time . 

26. A signal according to claim 25, wherein the timing information 
comprises coarse timing information and fine timing information. 

25 27. A signal according to claim 26, wherein the coarse and fine timing 

information are represented by separate words in the slot header. 

28. A signal according to claim 25, wherein the slot header includes data 
indicating whether or not the packet is a first packet. 

30 
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29. A signal according to claim 25, wherein the slot header includes data 
indicating packet type. 

30. A signal according to claim 29, wherein the data indicating packet type 
5 indicates one or both of (i) packet length; and (ii) whether the packet includes active 

error correction data. 

31. A signal according to claim 30, wherein each packet includes error 
correction data. 

10 

32. A signal according to claim 31, wherein the slot header includes data 
indicating whether or not the slot contains error correction data. 

33. A signal according to claim 32, wherein each slot contains error 
1 5 correction data. 

34. A signal according to claim 25, wherein the slots of each block are of 
fixed length and have predetermined positions in the block. 

20 35. A signal according to claim 25, wherein the said data blocks are 

variable length blocks. 

36. A signal according to claim 35, wherein the said slots are variable 
length slots. 

25 

37. A signal according to claim 36, wherein the variable length slots 
comprise slots containing metadata and slots containing data described by the 
metadata. 



30 38. A signal according to claim 37, wherein a metadata slot precedes the 

data slots containing the data described by the metadata in the metadata slot. 
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39. A signal according to claim 38, wherein the metadata slot contains 
metadata identifying a succeeding slot which contains a said first packet. 

5 40. A signal according to claim 36, wherein the variable length slots 

comprise a data field, a Type field containing data describing the type of data in the 
Data field and a Length Field defining the length of the data in the data field. 

41. A signal according to claim 25, wherein the blocks and block headers 
10 conform to SDTI. 

42. A signal according to claim 35, wherein the said packets are MPEG 2 
TS packets or ATM cells or Internet Protocol Packets. 
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ABSTRACT OF THE DISCLOSURE 
DTGTTAL SIGNAL PROCESSING AND SIGNAL FORMAT 
A digital signal comprises, data blocks, each data block including a header 
5 containing data relating to the block and a plurality of slots. Each slot has a slot header 
relating to the slot and a data packet. The data packets contain successive parts of 
information from a source. A first slot contains a first packet containing a first part of 
the said information from the source also contains a reference time. The or each 
subsequent slot contains a subsequent packet of the information from the said source 
10 also timing information defming the timing of that packet relative to the reference 
time. 

An encoder which encodes such a signal is provided. The corresponding 
decoder is enabled to correctly output the packets to allow correct decoding. Absolute 
delay of the packets has no effect on decoding. Jitter ( i.e. variation in the timing of 

15 the packets relative to each other) may corrupt the decoding. The decoder compares 
the timing information of each packet with an internal clock set by the reference time 
of the first packet and outputs the packets when the clock time equals the packet time 
thus at least reducing the jitter. 

The data blocks may be SDTI fixed length blocks and in a transmission system 

20 the packets are MPEG 2 TS packets, which are transmitted via an SDTI system. The 
data blocks may be SDTI variable length blocks and the packets may be MPEG2 TS 
packets, ATM cells or hitemet Protocol packets. 

25 (Figure 3) 
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1438 bytes (270Mbps), 1918 bytes (360Mbps) 2 bytes 
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Fig. 1 : Format of the SDTI-TS Fixed Block 
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MPEG-2 Transport Stream 
Packet (188 bytes) 



Fig. 2a : MPEG-2 Transport Stream Packet 
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MPEG-2 Transport Stream 
Packet (188 bytes) 
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Fig. 2b : MPEG-2 Transport Stream Packet 
with Active 16 bytes FEC 
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Fig. 2c : MPEG-2 Transport Stream 
Packet with Null FEC Space 
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Fig. 4 : Payload Header Structure 
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TS Slot Count Values: 
S, S+x, S+2x, S+3x, 
S+4x, S+5x, S+6x. 
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Fig. 5 : SDTI-TS Timing Reconstruction 
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Fig. 11 : TLD Block 
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Fig. 12 : Hierarchy of SDTI Variable Blocks 
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or their duly appointed associate, my attorneys, with full power of substitution and revocation, to prosecute this 
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receive the Patent, and to transact all business in the Patent and Trademark Office and in the Courts in connection 
therewith, and specify that all communications about the application are to be directed to the following correspondence 
address: 
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c/o FROMMER LAWRENCE & HAUG LLP 
745 Fifth Avenue to the attention of: 

New York, New York 10151 WILLIAM S. FRCWHER 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on 
information and belief are believed to be true; and further that these statements were made with the knowledge that 
willful false statements and the like so made are punishable by fine or imprisonment, or both, under Section 1001 of 
Title 18 of the United States Code and that such willful false statements may jeopardize the validity of the applicatio 
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[if all inventors have the same post office address] The Heights, Brooklands 

Weybridge KT13 OXW, England, United Kingdom 

Note: In order to qualify for reduced fees available to Small Entities, each inventor and any other individual or en1 
having rights to the invention must also sign an appropriate separate "Verified Statement (Declaration) Claiming [or 
Supporting a Claim by Another for] Small Entity Status" form [e.g. for Independent Inventor, Small Business Concern, 
Nonprofit Organization, individual Non-Inventor] . 
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